home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Games of Daze
/
Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso
/
x2ftp
/
msdos
/
libs
/
graphsrc
/
g3.doc
< prev
next >
Wrap
Text File
|
1989-02-21
|
5KB
|
119 lines
NAME
g31.c, g32.c, g3.h - portable Core System graphics package
DESCRIPTION
This is a portable implementation of the Core System graphics
package intended for implementation on microcomputers with graphics
approximately equivalent to the IBM PC. The Core System is
described in Computer Graphics vol 13, no 3 (Aug 79), reprints of
which are available from the Association for Computing Machinery
(item number 428791). You can call ACM at 1-800-526-0359, ext.
75, to order a copy.
I chose to implement the Core System because it was designed from
the ground up to be a three dimensional standard (unlike GKS, for
example).
Three classes of upward compatible levels are specified for Core
Systems; one class for output, one class for input, and one class
concerning dimensionality. This implementation has:
Output level 1: basic output
There are no retained segments or image transformations
(not to be confused with viewing transformations, which
are of course provided). Of the text primitives, only
text() is provided, and text is generated only in
"string_precision" (CHARPLANE, CHARUP, CHARPATH, and
CHARSPACE not implemented). This means that strings
are always displayed from left to right, and there are
no tilted characters.
Input level 1: no input
A simple cursor key interface is provided.
Dimension level 2: three dimensional
All 2D and 3D viewing transformations are provided.
Some inquiry and setting functions have not been implemented - for
example, set_viewing_parameters(viewing_parameter_array). Some viewing
operation functions may still follow the definitions in the 1977 draft
of the Core System.
None of the "raster extensions" have been implemented.
USAGE
A program using G3 consists of three layers of software. First is the
application software, which interacts with the user, reads data, and
generates an image in "world coordinates" using calls to the output
primitives. Second is the Core System graphics package itself
(files G31.C and G32.C) which converts the image from world
coordinates (doubles) to screen coordinates (integers). The third
layer deals with the graphics hardware and is therefore machine
dependent.
One way to structure the application program is as follows:
<read_data>
<initialize>
do {
<specify coordinate transformation>
<open segment>
<generate image>
<close segment>
<get input from user>
} while (not_finished);
<terminate>
For examples, see GRAPH, DOTS, and GLOBE.
IMPLEMENTATION
This package was written for the DeSmet C compiler. G31 and G32 are
entirely in C, and are not known to depend on the operating system.
The interface routines such as GPC and GZ are partly assembly
language, which the DeSmet compiler permits to be intermingled with
the C code. They require MS-DOS 2.0 or higher (because of their
use of the environment).
This implementation was written with approximately these priorities:
(1) correctness (freedom from visible glitches), (2) speed, and (3)
functionality.
This package requires a set of interface variables and
functions for each machine. I've written these device drivers
for CGA, EGA, and Hercules adaptors on an IBM, the Zenith
Z-100, the Houstin Instruments DMP-29 and Hewlett Packard 7470A
plotters, Postscript, and the CIE LIPS-10 laser printer. Some
of these drivers implement more than one graphics modes. The
user chooses among modes by setting the environment variable
GRAPHICS to a number. Similarly, the environment variable
PLOT_PORT has the name of the output port for a plotter or
printer. I chose that method so the application software would
remain ignorant of the existence of multiple modes. (This does
mean that the application software should initialize the
graphics before using any of the variables declared in G.H.) An
alternative would be to put equivalent data into a
configuration file.
I'd be glad to work with anyone who wants to port the package
onto other computers or other compilers. Anyone attempting
this for a display screen should use BENCH to verify their
implementation.
There are many things I haven't implemented. I'd especially
like to see some of the raster extensions, like area fill and
hidden line removal. Note - the Core System package currently
does not require the line erase function. It will require that
function if is extended to include retained segments. If no
line erase function is defined, the variable erase_line should
be set to point to the line drawing routine.
AUTHOR
Copyright (c) 1985 - 1989 by James R. Van Zandt
(jrv@mitre-bedford) 27 Spencer Dr., Nashua NH 03062, 603-888-2272.
Resale forbidden, copying for personal use encouraged.
Constructive comments welcome.